Modern computers offer the capability of multi-tasking, that is, running more than one application at once. Consequently, many users frequently have open on their computer desktops numerous application windows at a time. For example, a user may cause his or her computer to simultaneously run multiple applications, possibly including, for example, a word processor, a web browser, a telnet session window, a terminal client emulator, an instant messaging (IM) client, an e-mail client, etc. While only one window may be active, i.e., available for the user to provide input to, at a time, different windows may be made active by the simple click of a mouse, selection of toggle keys (e.g., ALT-TAB in WINDOWS® operating system), etc. Frequently, because users are unaware or confused as to which application window is active, users will provide textual input intended for one application window to another. For example, it is not uncommon for users to enter a text string intended for one application in another application's window.
In many cases, providing textual input to the wrong application window, while irritating and inconvenient to the user, is nonetheless innocuous. For example, providing textual input to a window not configured to accept such has no effect at all, other than requiring the user to re-input text once the correct application window is made active. In other cases, providing textual input to the wrong application window is more inconvenient, e.g., causing the user to have to cut text from a word processor window and paste it into a spreadsheet window. Yet other cases present more serious concerns. For example, providing textual input to an IM window that was intended for another window can have serious ramifications because such a user error could result in the transmission of textual information to third parties that the user wishes to keep private and/or secure. Moreover, the risk of such inadvertent transmission is high, because IM client windows can look like other windows requiring the entry of information such as user identifiers and passwords, e.g., telnet windows, web browsers, terminal client emulators, etc. Further, once mistakenly-entered textual information has been provided to an IM client and sent to an IM server, it is impossible to recover or protect.
Presently, applications such as IM clients have limited mechanisms for detecting and protecting mistakenly entered textual data. For example, some IM clients include a feature known as “auto-correct” that detects strings identified by the user and, in real-time or near real-time, and automatically replaces those strings with other strings as specified by the user. However, auto-correct functionality as presently known suffers from a number of significant drawbacks.
First, present auto-correct features generally do not operate until after a limiting character such as a space character or a carriage return character has been entered. However, few user identifiers and passwords include limiting characters such as space characters or carriage return characters. Therefore, present auto-correct features generally will not detect a mistakenly entered user identifiers and password until after a user has selected an “enter” key or other mechanism for transmitting confidential information such as a user name and password.
Further, auto-correct features usually depend on a dictionary file that is generally not encrypted, and that is generally stored in plain-text format. Thus, from a security perspective, present auto-correct features offer little protection.
Moreover, present auto-correct functionality is designed to substitute correct text for incorrect text. However, in the case where a sensitive text string, such as a password, is being entered, the exact opposite of auto-correct functionality is desired. That is, when a password or other sensitive text string is accidentally entered into an input window such as an IM client, it would be advantageous to replace the actual password or other correct text string with an incorrect representation of the text string.
Accordingly, what is needed is the ability to detect predetermined text string in real-time or near real-time with depending on the entry of a specific character. What is also needed is the ability to store and retrieve pre-determined text strings from an encrypted database or file, thus ensuring the security of sensitive data. Further, what is needed is the ability to replace a correct text string or actual representation of a sensitive text string with an incorrect representation of the string so as to avoid the accidental sharing of sensitive information.